home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 1998 November / IRIX 6.5.2 Base Documentation November 1998.img / usr / relnotes / arraysvcs / chA.z / chA
Text File  |  1998-11-02  |  3KB  |  67 lines
  1.  
  2.  
  3.  
  4.                                   - 1 -
  5.  
  6.  
  7.  
  8.        1.  _S_e_c_u_r_i_t_y__C_o_n_s_i_d_e_r_a_t_i_o_n_s
  9.  
  10.        The array services daemon, arrayd(1M), runs as root.  As
  11.        with other system services, if it is configured carelessly
  12.        it is possible for arbitrary and possibly unauthorized users
  13.        to disrupt or even damage a running system.
  14.  
  15.        By default, most array commands are executed using the user,
  16.        group and project ID of either the user that issued the
  17.        original command, or else those of a fairly powerless user,
  18.        such as guest.  When adding new array commands to
  19.        arrayd.conf, or modifying existing ones, always use the most
  20.        restrictive IDs possible in order to minimize trouble if a
  21.        hostile or careless user were to run that command.  Avoid
  22.        adding commands that run with "more powerful" IDs (such as
  23.        user "root" or group "sys") than the user.  If such commands
  24.        are necessary, analyze them carefully to ensure that an
  25.        arbitrary user would not be granted any more privileges than
  26.        expected, much the same as one would analyze a "setuid"
  27.        program.
  28.  
  29.        In the default array services configuration, arrayd assumes
  30.        that a remote user will accurately identify itself when
  31.        making a request.  In other words, if a request claims to be
  32.        coming from user "abc", arrayd will assume that it is in
  33.        fact from user "abc" and not somebody spoofing "abc".  This
  34.        should be adequate for systems that are behind a network
  35.        firewall or otherwise protected from hostile attack, and in
  36.        which all the users inside the firewall are presumed to be
  37.        non-hostile.  On systems where this is not the case (for
  38.        example, those that are attached to a public network, or
  39.        where individual machines otherwise cannot be trusted),
  40.        array services authentication should be used.  When
  41.        authentication is enabled, all requests from remote systems
  42.        will be authenticated using a mechanism that involves
  43.        private keys that are known only to the super-users on the
  44.        local and remote systems.  Requests originating on systems
  45.        that do not have these private keys will be rejected.  For
  46.        more details, see the section on "Authentication
  47.        Information" in arrayd.conf(4).
  48.  
  49.        arrayd does not support mapping user, group or project names
  50.        between two different namespaces; all members of an array
  51.        are assumed to share the same namespace for users, groups
  52.        and projects.  Thus, if systems "A" and "B" are members of
  53.        the same array, then username "abc" on system A is assumed
  54.        to be the same user as username "abc" on system B.  This is
  55.        most significant in the case of username "root".
  56.        Authentication should be used if necessary to prevent access
  57.        to an array by machines using a different namespace.
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.